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ABSTRACT 

POSE (relative position and attitude) can be computed in many different ways. Given a sensor that measures bearing to 
a finite number of spots corresponding to known features (such as a target) of a spacecraft, a number of different 
algorithms can be used to compute the POSE. NASA has sponsored the development of a flash LIDAR proximity 
sensor called the Vision Navigation Sensor (VNS) for use by the Orion capsule in future docking missions. This sensor 
generates data that can be used by a variety of algorithms to compute POSE solutions inside of 15 meters, including at 
the critical docking range of approximately 1-2 meters. Previously NASA participated in a DARPA program called 
Orbital Express that achieved the first automated docking for the American space program. During this mission a large 
set of high quality mated sensor data was obtained at what is essentially the docking distance. This data set is perhaps 
the most accurate truth data in existence for docking proximity sensors in orbit. In this paper, the flight data from 
Orbital Express is used to test POSE algorithms at 1.22 meters range. Two different POSE algorithms are tested for two 
different Fields-of-View (FOVs) and two different pixel noise levels. The results of the analysis are used to predict 
future performance of the POSE algorithms with VNS data. 
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1. INTRODUCTION 

Spacecraft maneuvers depend on accurate information. The accuracy of the information is even more important when 
the spacecraft is maneuvering relative to another object in space. There are different types of sensors used to help 
measure the relative position and attitude, or POSE, between one spacecraft and another, but all of the sensors require 
algorithms to allow them to properly compute the POSE from the basic measurements they take. In general, the sensor 
measurements consist of a set of points on the target vehicle, such as the centroids of the spots seen on a target or 
particular features on the target vehicle. The POSE algorithm takes those sensor measurements as inputs and computes 
the relative position and attitude between the sensor and the target. 

The VNS was designed to provide data that would be sufficient to compute relative 6-Degree-of-Freedom (DOF) (3- 
DOF relative position and 3-DOF relative attitude) data when used with an appropriate target. The VNS and DragonEye 
space qualified flash LIDAR systems both provide intensity and range images of targets in their FOVs, but that image 
data must then be processed to be of use to a guidance, navigation, and control (GN&C) system. 


2. ANALYSIS 


2.1 POSE Algorithms 

Various POSE algorithms have been considered by the VNS team. These algorithms have been narrowed down to 
three, which will be described in more detail below, and two of those will be used with previously collected flight sensor 
data. Each of these algorithms can combine Time-Of-Flight (TOF) LIDAR range estimates for the spot locations with 
the POSE solutions. These alternate methods of solution that incorporate LIDAR range are not considered in this 
analysis, since no LIDAR range is available from Orbital Express data. Furthermore, the current VNS LIDAR range 
error is perhaps too high to be of use at the docking position, and it may not be useable. At the time of publication of 
this paper, it is very possible that for docking range estimates a solution based solely on POSE is likely. Regardless of 
the eventual nature of the solution method employed by VNS at the docking range, this paper focuses solely on the 
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POSE solution. In the Orion spacecraft, the VNS data will be processed by the Video Processing Unit (VPU). That unit 
consists of a set of processors, Field Programmable Gate Arrays (FPGAs), and software that can take sensor and video 
data and process it in real time. There are two POSE algorithms that will be used by the VPU that are discussed in detail 
in this paper. The first is called P3P. P3P is a method of finding a solution from the location of three and only three 
known locations on the target. It is based on the method of Finsterwalder [1] as adapted by Haralick et al [2], The 
problem is set up as a geometry problem and solved with a cubic and two quadratic polynomials. 

The other primary method of solving the POSE problem for VNS is called the Least Squares POSE or LSP. LSP 
consists of a way of combining more than three points together when they are available. It also follows the method 
outlined in Haralick. If LIDAR data is available for more than three spots, a third algorithm. Weighted Least Squares 
Program or WLSP is used. As noted above, this algorithm is beyond the scope of this paper. Due to the fixed error from 
LIDAR TOF solutions, which become a bigger percentage of the solution at close ranges, WLSP is thought to be more 
effective at improving the POSE solution at longer ranges. Since this paper focuses on the minimum range, the LIDAR 
range solutions are omitted and WLSP is not simulated. 

The P3P algorithm follows the solution method of Haralick [2], In this method, the camera measures exactly three 
image points on the target vehicle. These image points can be combined with information about the known geometry 
between those points on the target vehicle and the Law of Cosines can be used to form the following equations, 

Ri ~ + R2 ~ — 2 Rj R2 cos 0i2 - rnT = 0 

Ri ~ + R3 ~ — 2 R] R3 cos 0i3 - ri3 T = 0 

R2 ~ ' R3 ~ — 2 R2 R3 cos 023 — r 2 3 = 0 

where 0;j represents the relative angles between the points in the image, pj represents the physical distances between the 
points on the target vehicle, and Rj is the range from the sensor optical center to the physical points on the target vehicle 
(which is the translational solution desired). The P3P method uses a polynomial to solve these equations, which consist 
of three equations with three unknowns (Ri, R2, and R3). Other methods of solving the equations have been tried with 
other sensors [3]. 


2.2 Orbital Express Flight Data Overview 


In this section, flight results from the Orbital Express mission are used as a basis of simulation and comparison with 
VNS POSE Estimation algorithms. Orbital Express was launched in March of 2007 and operated until August of 2007. 
During operations, fifteen different data sets of proximity sensor data were collected while the chase and target vehicles 
were mated. These data sets represent a source of highly accurate truth data due to the tight tolerance on the Orbital 
Express docking mechanism. The variation in bias from set to set is small and significantly less than the Orbital 
Express docking sensor specification. The Orbital Express primary docking sensor was the Advanced Video Guidance 
Sensor or AVGS. 

It is important to stress that in the experience of the authors, the test data for the AVGS while docked on Orbital Express 
can be considered the most accurate truth data in existence for this type of sensor. Ground testing accuracy has 
limitations [4], which can be reduced to the following statement: proximity sensors used for docking generally are 
required to be so accurate that any source of truth data for ground testing is likely to be of the same order or less in 
accuracy. This is particularly true considering that all known proximity sensors use lenses and thus optics plays a role. 
Attempting to measure the focal plane of a sensor in situ, for example, has proven difficult in the past. There are also 
other sources of error and problems with getting accurate truth data in ground testing. 

By contrast, the docking mechanism on Orbital Express had a tight tolerance that was automatically repeated every time 
an operation was performed, and in the process hours of data were collected in the mated position. In fact, three of the 
fifteen tests were specifically conducted to calibrate or characterize the performance of the Orbital Express chase vehicle 
proximity sensor suite. Two sets of ground data in the mated position were also taken in the clean room in Titusville, 
Florida, prior to launch, further increasing the value of the on-orbit data set by providing a pre-launch set of data for 



comparison. Finally, the value of the on-orbit data is significantly improved over any ground set of data by virtue of the 
fact that it was taken in the relevant environment and incorporated environmental effects such as vacuum, on-orbit 
thermal effects and on-orbit lighting (sunlight, shadow, darkness, and earth background). 

The key to using AVGS Orbital Express data to test VNS algorithms is to convert the AVGS inputs into the VNS input 
format used by the simulation software. Both sensors use target spot locations measured by the camera as inputs into 
the POSE Estimation algorithms. These inputs were preserved along with the AVGS output data and so are available 
for use with the VNS POSE Estimation algorithms. Flowever, the basic VNS POSE Estimation software is not 
currently configured to receive large inputs of target spot locations in batch mode. Instead, the VNS simulation software 
Monte Carlo POSE Estimation (MCPE) can accept as user input two truth solutions and a pixel noise parameter. MCPE 
then randomly selects a truth case that is between the two solutions, calculates target spot locations for the selected truth 
case, adds pixel noise to the simulated target spots, and finally regenerates the solution with pixel noise. The user can 
choose an arbitrary number of these generated solutions. For the purposes of testing in this paper we use 1000 cases. 


2.3 Flight Data Conversion to VNS Format 

During the Orbital Express mission, several different scenarios were run. The scenarios involving free-flight were 
Scenario 2-1, Scenario 3-1, Scenario 5-1, Scenario 7-1, Scenario 8-2, and EOL (End-of-Life) [5]. In addition, there were 
some other sensor checkouts that did not involve undocking and redocking, so the AVGS and the target were in the same 
position relative to one another as they had been the last time the sensor took measurements. The sensor checkouts were 
part of different utility inns with such names as AT-UTIL-25. The sensor data from the AVGS compared very nicely 
with the Kalman filter that was used to blend all of the spacecraft sensor data [6]. 

It was somewhat of a challenge to figure out how to make the Orbital Express data from the AVGS fit into MCPE 
without major code modifications. In order to discuss how this was accomplished, it is necessary to describe the Orbital 
Express AVGS data that was available. Table 1 and Table 2 present the results of all fifteen on-orbit data samples for 
the AVGS. These samples represent the truth data with one-sigma variations for each set. Notice also that the “truth 
position” wanders slightly from one position to the next. The slight variation between samples can be considered a bias, 
and represents the variation in the docking mechanism from case to case (there may be other factors causing the slight 
variations; but for the purposes of this paper, given how small the variations are, we assume that the differences are all 
due to mechanical variations in the docking mechanism due to tolerance, thermal variations, and mechanical 
deformation). The slight variation from case to case provides the bounds of the two truth solutions required by MCPE. 
The total minimum and maximum values from all fifteen cases for each solution parameter were selected and the results 
are tabulated in Table 3. 


Table 1: Orbital Express AVGS Mated Solution Data (Median Values) 



End of 
Life pre 

Sen 8-2 
pre 

Sen 8-2 
post 

Sen 7-1 
pre 

Sen 7- 
1 post 

Sen 5-1 
pre 

Sen 5-1 
post 

Sen 3- 
1 pre 

Sen 3-1 
post 

Duration [min] 

3.04 

3.01 

16.29 

3.03 

13.35 

3.03 

1.05 

3.03 

0.99 











Range [m] 

1.220 

1.220 

1.220 

1.220 

1.220 

1.219 

1.220 

1.220 

1.220 

Azimuth [deg] 

-0.008 

-0.009 

-0.004 

-0.009 

-0.010 

-0.011 

-0.015 

-0.006 

0.003 

Elevation [deg] 

-0.021 

-0.024 

-0.034 

-0.025 

-0.032 

-0.023 

-0.022 

-0.028 

-0.033 

Pitch [deg] 

0.000 

0.000 

0.091 

0.044 

0.024 

0.021 

0.052 

0.004 

0.021 

Yaw [deg] 

-0.028 

-0.049 

-0.014 

-0.105 

0.000 

0.000 

0.000 

-0.052 

-0.024 

Roll [deg] 

0.059 

0.066 

0.035 

0.098 

0.084 

0.049 

0.063 

0.091 

0.105 




Table 2: Additional Orbital Express AVGS Mated Solution Data 



Sen 2-1 
pre 

Sen 2-1 
post 

Sen 1-1 
post 

AT UTIL- 
25 (1st) 

AT UTIL- 
25 (2nd) 

Sensor 
Stress Test 
(AC3) 

Duration [min] 

3.02 

1.04 

0.46 

43.98 

22.10 

309.56 








Range [m] 

1.220 

1.220 

1.220 

1.220 

1.220 

1.220 

Azimuth [deg] 

-0.009 

-0.006 

-0.010 

-0.009 

-0.007 

-0.010 

Elevation [deg] 

-0.026 

-0.025 

-0.032 

-0.024 

-0.023 

-0.023 

Pitch [deg] 

0.000 

0.049 

0.053 

0.028 

0.035 

0.010 

Yaw [deg] 

-0.045 

-0.056 

-0.045 

-0.038 

0.000 

0.000 

Roll [deg] 

0.098 

0.126 

0.122 

0.094 

0.101 

0.084 


A further complication is that the solution of the VPU is in a different format from that of the AVGS. The attitude 
portion of the solution is identical, but the translational range of the VNS is output as Cartesian coordinates (X, Y, and 
Z) while the AVGS outputs the same information in a range/bearing angle format (Range, Azimuth, and Elevation). 
Thus, for purposes of comparing the respective solutions, the AVGS Range, Azimuth, and Elevation are converted to 
VNS X, Y, and Z. The conversion is straightforward, and the results appear in Table 3. Table 3 presents the upper and 
lower bounds of the AVGS case-to-case bias for all fifteen samples in the VNS coordinate frame, with the Euler angle 
data repeated for convenience. Thus, when MCPE generates a random sample between the two sets of solution data 
(i.e. the Minimum data set and the Maximum data set) in Table 3, it is essentially selecting a random bias for the given 
run. Each of the 1000 MCPE solutions will then have a different fixed random bias. 

Table 3: Minimum and Maximum AVGS Solutions in Orbital Express Mated Positions 


Parameter 

Min 

Max 

X (mm) 

-0.319 

0.0639 

Y (mm) 

-0.723 

-0.447 

Z (mm) 

1219 

1220 

Pitch (deg) 

-0.016 

0.086 

Yaw (deg) 

-0.050 

0.016 

Roll (deg) 

0.035 

0.126 


The next step is to convert the noise of the AVGS target spots into VNS target spots in the appropriate format. AVGS 
input target spot locations are available with the solution data as ordered pairs of spot locations in an Azimuth-Elevation 
format. There are four spot locations total. The VNS simulator’s noise parameter input is Root Sum Square (RSS) 
pixel noise. The AVGS angular spot location coordinates are converted to VNS x-pixel and y-pixel coordinates with a 
simple linear gain, and the two VNS pixel coordinates combined into the RSS pixel noise used by MCPE. Table 4 lists 
the AVGS spot centroid noise levels and the corresponding Elevation and Azimuth noise in degrees. MCPE takes this 
as input a one-sigma pixel noise and applies it to simulated spot locations using a random white-noise Gaussian 
distribution. This noise must be calculated on the basis of the size of the FOV and number of pixels for a given sensor. 
In this analysis both the AVGS FOV and VNS FOV are simulated, so we describe the relevant pixel noise used for each 
below. The noise is converted from Table 4 into a single RSS pixel noise parameter for input into MCPE. 





Table 4: AVGS RSS Spot Noise from Orbital Express Mated Positions 



Azimuth 

Elevation 

Units 

Spot 1 

0.004218 

0.003557 

deg 

Spot 2 

0.004359 

0.003885 

deg 

Spot 3 

0.004567 

0.003640 

deg 

Spot 4 

0.003811 

0.003649 

deg 

RSS 

0.004239 

0.003683 

deg 


As mentioned above, both the AVGS and VPU convert target spot locations into solutions. The reference points used by 
the AVGS are described as the “target matrix” by AVGS programmers. The target matrix is simply a list of the 
locations of the AVGS spots in the body frame of the target assembly used by AVGS. This target assembly consists of 
corner cube reflectors and appears in Fig. 1. These locations have been converted into the VNS target body coordinate 
frame used by MCPE and appear in Table 5. The spot locations are loaded in the order they were entered into MCPE, 
and not the OE AVGS nomenclature. Fig. 1 also shows the geometric relationship of the spots in the VNS coordinate 
system as numbered in Table 4. 


Table 5: AVGS Target Spot Locations in VNS Coordinates (cm) 


Spot # 

X 

Y 

Z 

1 

6.32765 

-0.03168 

- 6.26298 

2 

-6.36587 

-0.06732 

-6.19930 

3 

-0.03398 

6.29857 

-6.29040 

4 

0.00000 

0.00000 

-1.17856 
















Fig. 1: AVGS Orbital Express Target Assembly with VNS Target Spot Numbering Scheme 


2.4 Test Case Description 

The purpose of this effort is to use Orbital Express data to characterize the performance of the POSE algorithms 
expected to be used by the VPU with VNS data. One way to do this is to simulate the AVGS FOV and imager pixel size 
in MCPE and compare the results to those obtained on orbit. The only difference in the two cases would be the POSE 
algorithms. As detailed above, AVGS uses the Inverse Perspective while the VPU uses P3P. Each of these algorithms 
uses only three points. This will be Test Case #1. 

The VPU can also use the LSP algorithm to incorporate more than three spots. Since there were four spots available on 
Orbital Express, it makes sense to see if LSP can improve the solution by using the fourth spot. This will be Test Case 
# 2 . 

Next, it’s interesting to see how the VNS FOV and imager pixel size would have worked for Orbital Express, and to see 
if it would meet specification. Thus, Test Cases #3-4 repeat Test Cases #1-2 with the VNS FOV and imager pixel size 
replacing that of the AVGS. 

The spot noise generated by the AVGS on-orbit is captured in Table 5. This noise is in degrees and on the Azimuth and 
Elevation axes. Table 6 converts this noise into the RSS combined axis pixel noise for all of the Test Cases. 



Table 6: Test Case Description 


Test Case 

Pixel Noise 

FOV (deg) 

# of Pixels 

Algorithm 

1 

0.07168 

20 

256 

P3P (3 Spots) 

2 

0.07168 

20 

256 

LSP (4 Spots) 

3 

0.10000 

20 

256 

P3P (3 Spots) 

4 

0.10000 

20 

256 

LSP (4 Spots) 


3. DISCUSSION OF RESULTS 


3.1 Overview 

This section will present the results achieved for the test cases outlined above. The test cases are organized in three 
groups of two, with the distinguishing feature between the two in each group being the particular POSE algorithm 
simulated. All the test cases will therefore be discussed in groups of two. 

Table 7: AVGS Flight Data Standard Deviations 


X (mm) 

0.078 

Y (mm) 

0.079 

Z (mm) 

0.564 

Pitch (deg) 

0.035 

Yaw (deg) 

0.037 

Roll (deg) 

0.027 


Before presenting the results of the simulations, we first present in Table 7 the AVGS truth data from the mated Orbital 
Express positions. Table 7 presents the one-sigma variations of the AVGS solution from the on-orbit flight data 
presented in Tables 1 and 2. The AVGS Range-Az-El translational portion of the solution has been converted into the 
VNS X-Y-Z solution to allow a one-to-one comparison. All four test cases will be compared to this result, and to each 
other. 

3.2 VNS Image Spot Test Cases with AVGS Pixel Noise 

Tables 8 and 9 display the results from the VNS FOV and imager number of pixels. There is a roughly 10-12 % 
improvement from the 3-spot (P3P) solution to the 4-spot (LSP) solution. The data is roughly five times less accurate 
than the AVGS truth data in Table 7. The combination of 75% fewer pixels in the VNS and the 25% larger FOV of the 
VNS compared to the AVGS most likely accounts for this difference in accuracy. 





Table 8: Test Case 1 Results 


Table 9: Test Case 2 Results 


Parameter 

1-Sigma Error 

X (mm) 

0.2000 

Y (mm) 

0.2000 

Z (mm) 

1.7000 

Pitch (deg) 

0.1729 

Yaw (deg) 

0.1609 

Roll (deg) 

0.0766 


Test Case 

1-Sigma Error 

X (mm) 

0.1000 

Y (mm) 

0.1000 

Z (mm) 

1.5000 

Pitch (deg) 

0.1528 

Yaw (deg) 

0.1477 

Roll (deg) 

0.0698 


3.3 VNS Image Spot Test Cases with Specified Pixel Noise 

The next two test cases repeat the previous two with the VNS specified pixel noise of 0.1 pixels substituted for the 
flight-data-derived value of 0.07168 used above. The results of the MCPE Monte Carlo simulations using P3P (Test 
Case 10) and LSP (Test Case 11) appear in Tables 10 and 11. It can be seen that the result of using a higher pixel noise 
is a corresponding increase in inaccuracy, at a level commensurate with the increase in noise. 


Table 10: Test Case 3 Results 


Table 11: Test Case 4 Results 


Parameter 

1-Sigma Error 

X (mm) 

0.2000 

Y (mm) 

0.2000 

Z (mm) 

2.1000 

Pitch (deg) 

0.2312 

Yaw (deg) 

0.2140 

Roll (deg) 

0.0966 


Parameter 

1-Sigma Error 

X (mm) 

0.2000 

Y (mm) 

0.2000 

Z (mm) 

2.2000 

Pitch (deg) 

0.2173 

Yaw (deg) 

0.2050 

Roll (deg) 

0.0949 













Although at the time of publication of this paper no official specification of the VPU or VNS has been published, some 
notional values from an unofficial source appear in Table 12. These values are included only for comparison, and should 
not be considered official in any way. 


Table 12: Notional Specification for POSE solutions from VNS data 


Distance 
To Target 

Lateral 

Position 

Error 

Range 

Error 

Relative 
Attitude 
Error 
(pitch and 
yaw axis) 

Relative 
Attitude 
Error 
(roll axis) 

2m 

(6.56 ft) 

±1.3 mm (±0.051 in) 

±7.6 mm 
(±0.30 in) 

±0.14 degree 

±0.34 degree 

15m 
(49.2 ft) 

±4.7 cm 
(±1.85 in) 

±4.4 cm 
(±1.73 in) 

±0.63 degree 

±0.61 degree 


Viewing the values listed in Table 12, we can see that the VNS as-is would not meet specification for the pitch or yaw 
error at 2 meters using either the flight-data-derived pixel noise of 0.07168 or the specified noise of 0.1000. However, 
all the other parameters would be well within specification. The pitch and yaw would have approximately a 20% 
increase in error with the flight-data-derived noise level and a roughly 50% increase in error with the VNS-specified 
pixel noise. 


4. CONCLUSIONS AND FUTURE WORK 


Certain selected truth data from Orbital Express has been used to simulate results for the VNS sensor. The accuracy of 
the POSE solutions that can be calculated from VNS data is seen to have a strong dependency on the FOV and number 
of imager pixel differences from the AVGS. Two levels of pixel noise were simulated. The first is that seen by the 
AVGS on orbit, adjusted for the VNS FOV and number of pixels. The specified value is higher and leads to a 
corresponding loss of accuracy in the solution. 

A comparison to a notional specification shows that the VNS would have trouble meeting this specification if the target 
used by the VNS were identical to that used for Orbital Express and for the proposed VNS FOV, number of pixels, and 
pixel noise. Since this specification is notional, nothing is implied about the ability of the VNS to meet any 
specification. Rather, this investigation gives an indication of what level of accuracy could be expected for the given 
FOV, number of pixels and specified pixel noise of the VNS. A target was installed on the International Space Station 
(ISS) to provide reflectors at known locations for use by the VNS [7]. This target has a baseline that is more than double 
that used for the AVGS and a pole that is approximately six times as tall. This target size will allow for much more 
accurate POSE computations since the pixel noise will be a much smaller percentage of the spot spread, and the taller 
pole causes more motion for a given angle, making a sensor more sensitive to measuring the relative pitch and yaw. 

It should be noted in closing that pixel noise is only one potential source of error for proximity sensors used for docking, 
and that other sources of error can be far larger. Further investigations could consider modeling other error sources 
using either existing simulations like MCPE or other existing software tools available to the authors. At the time this 
paper is submitted to the conference, the launch date of STS- 134 is April 29, 2011, and this paper is scheduled to be 
presented a few days earlier. STS-134 includes a Detailed Test Objective (DTO) called STORRM (Sensor Test for 
Orion RelNAV Risk Mitigation) which will test a version of the VNS in open loop during the shuttle’s approach to the 
ISS. The results of this test could be used in conjunction with the results of this analysis for future studies. 
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